Day2 - GPT 陪我讀 W3C Trace Context Ch1
Day3- GPT 陪我讀 W3C Trace Context Ch2
Day4- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第一部份
Day5- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第二部份
Day6- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第三部份
Day7- GPT 陪我讀 W3C Trace Context Ch4
Day8- GPT 陪我讀 W3C Trace Context Ch5-6

前言

第 3 章：分散式追踪規範
隨著現代複雜分散式系統的增長，追踪不同組件之間的交互和性能變得越來越重要。第 3 章著重於分散式追踪的標準化，尤其集中在如何標記、收集和傳播追踪數據。本章提供了一個全面的框架，用於理解和應用分散式追踪，以支援系統分析、監控和故障排除。

在此章節中，您將找到以下重點主題：

1. 取樣標誌：一個用於指示是否已記錄追踪數據的特殊標誌。這有助於控制記錄量和追踪的成本。
2. 記錄決策和技術：詳細描述了追踪記錄的各種方法和策略，以及如何在效率和效能之間取得平衡。
3. 互操作性和供應商溝通：探討了如何在不同供應商和服務之間實現一致的追踪，以及如何改善客戶體驗。
4. 版本控制和未來考量：介紹了如何管理不同版本的追踪規範，並留出空間以容納未來的擴展和改進。
5. 安全和最佳實踐：提供了一組供應商應遵循的建議和規則，以確保追踪數據的安全和正確使用。

本章為任何希望深入了解分散式追踪的讀者提供了實用的指南和標準，無論是開發人員、系統工程師還是解決方案提供商。透過本章的指導，讀者可以更好地理解和應用分散式追踪，從而提高系統的可見性和可靠性。

Ch3 追蹤上下文 HTTP header格式

此部分描述分散式追蹤上下文與 traceparent 和 tracestate HTTPheader的綁定。

3.1 header之間的關係

• traceparent header以通用格式表示追蹤系統中的傳入請求，所有供應商都能理解。

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

• tracestate header以特定供應商的格式包括父項。

tracestate: congo=t61rcWkgMzE

例如，一個客戶端和伺服器使用不同的追蹤供應商，如 Congo 和 Rojo。客戶端在 Congo 系統中追蹤，並將以下header添加到出站 HTTP 請求。

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
tracestate: congo=t61rcWkgMzE

注意：在此情況下，tracestate 值 t61rcWkgMzE 是 Base64 編碼父 ID（b7ad6b7169203331）的結果，儘管不需要進行此類操作。

接收服務器，在 Rojo 追踪系統中追踪，保留了收到的 tracestate 並在左側添加了一個新條目。

traceparent: 00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01
tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE

注意：ucfJifl5GOE 是 Base64 編碼的父 ID b9c7c989f97918e1。

當 Congo 寫下其 traceparent 條目時，請注意，它沒有編碼，這有助於保持一致性，供那些進行相關性分析的人使用。但是，其條目 tracestate 的值被編碼並與 traceparent 不同。這是可以的。

最後，您將看到 tracestate 保留了 Rojo 的條目，除了推向右側以外，完全一樣。最左側的位置讓下一個服務器知道哪個追踪系統與 traceparent 相對應。在這種情況下，由於 Congo 寫了 traceparent，所以它的 tracestate 條目應該在最左側。

3-1 小結

這一章節描述了如何將分散式追踪信息繫結到兩個 HTTP header：traceparent 和 tracestate。

traceparent：這個header包含了追踪的通用信息，這使得不同的供應商可以理解和解析。
tracestate：這個header包含了供應商特定的信息，這允許不同的追踪系統在不破壞彼此的情況下進行協作。
在上述示例中，不同的追踪系統（Congo 和 Rojo）如何協同工作進行了說明。在分散式追踪中，這兩個header讓追踪信息在多個不同的服務和供應商之間透明地流通。

通過這種方式，無論在系統中使用哪個追踪供應商，都可以建立一個完整的請求追踪圖。這有助於識別和診斷系統中的問題，提供了更好的可見性和可維護性。

3.2 Traceparent header

traceparent HTTP header字段在追踪系統中識別傳入請求。它有四個字段：

• 版本（version）
• 追踪 ID（trace-id）
• 父 ID（parent-id）
• 追踪標誌（trace-flags）

3.2.1 header名稱

header名稱：traceparent

為了增加跨多個協議的互操作性並鼓勵成功集成，供應商應默認將header名稱SHOULD保持為小寫。header名稱是一個沒有任何分隔符的單詞，例如連字符（-）。

供應商必須期望header名稱為任何情況（大寫，小寫，混合），並應將header名稱發送為小寫。

3.2.2 traceparent header字段值

本節使用 [RFC5234] 的增強巴科斯 - 納爾形式（ABNF）表示法，其中包括該文檔的 DIGIT 規則。DIGIT 規則定義了單個數字字符 0-9。

以下是一些規則定義：

HEXDIGLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"；小寫十六進制字符
value = version "-" version-format

連字符（-）用作字段之間的分隔符。

3.2.2.1 version

version = 2HEXDIGLC；本文檔假設版本 00。

版本 ff 是禁止的。該值是 US-ASCII 編碼的（這是 UTF-8 兼容的）。

版本（version）是 1 個字節，代表 8 位無符號整數。版本 ff 無效。當前規範假設版本設置為 00。

3.2.2.2 version-format版本格式

以下version-format定義用於版本 00。

version-format = trace-id "-" parent-id "-" trace-flags
trace-id = 32HEXDIGLC；16 字節數組標識符。所有零禁止
parent-id = 16HEXDIGLC；8 字節數組標識符。所有零禁止
trace-flags = 2HEXDIGLC；8 位標誌。目前僅使用一個位。有關詳細信息，請參見下文。

3.2.2.3 Trace-id 追蹤 ID

這是整個追踪鏈路的 ID，用於通過系統唯一識別分散式追踪。它表示為 16 字節數組，例如，4bf92f3577b34da6a3ce929d0e0e4736。
所有字節為零（00000000000000000000000000000000）被視為無效值。

如果Trace-id 值無效（例如，如果它包含不允許的字符或全部為零），供應商必須忽略 traceparent。

3.2.2.4 parent-id 父 ID

這是呼叫方所知的此請求的 ID（在某些追踪系統中，這被稱為 span-id，其中 span 是客戶端請求的執行）。它表示為 8 字節數組，例如，00f067aa0ba902b7。所有字節為零（0000000000000000）被視為無效值。

供應商MUST在父 ID 無效時忽略 traceparent（例如，如果它包含非小寫十六進制字符）。

3.2.2.5 trace-flags 追蹤標誌

一個 8 位字段，用於控制追踪標誌，例如取樣，追踪級別等。這些標誌是呼叫方提出的建議，而不是要遵循的嚴格規則，原因有三：

• 信任和濫用
• 呼叫方中的錯誤
• 呼叫方服務和被調用方服務之間的不同負載可能會迫使被調用方降低取樣率。

您可以在此規範的安全考慮部分找到更多信息。

和其他字段一樣，trace-flags是十六進制編碼的。例如，所有 8 個標誌設置為 ff，沒有標誌設置將為 00。

由於這是一個位字段，因此您不能通過解碼十六進制值並查看結果數字來解釋標誌。例如，標誌 00000001 可以用十六進制編碼為 01，或者如果與標誌 00001000 一起呈現，則可以用十六進制編碼為 09。位字段中的一個常見錯誤是在解釋標誌時忘記屏蔽。

以下是正確處理追踪標誌的示例：

static final byte FLAG_SAMPLED = 1; // 00000001
...
boolean sampled = (traceFlags & FLAG_SAMPLED) == FLAG_SAMPLED;

3.2.2.5.1 Sampled flag 取樣標誌

當前的規範版本（00）僅支援名為取樣（sampled）的單一標誌。

當設置時，最低有效位（最右邊的位）表示呼叫方可能已經記錄了追踪數據。未設置時，表示呼叫方並未在頻帶外記錄追踪數據。

分散式追踪可能被以下情況破壞：

• 只記錄一部分請求會導致追踪中斷。
• 記錄所有收入和支出請求在負載下變得極為昂貴。
• 隨機或特定組件的數據收集決策導致所有追踪中的數據碎片化。

由於這些問題，追踪供應商會做出自己的記錄決策，並且對於這項工作的最佳算法並無共識。

各種技術包括：

• 概率取樣（通過拋硬幣對 100 個分散式追踪中的 1 個進行取樣）
• 延遲決策（根據請求的持續時間或結果做出收集決策）
• 延遲取樣（讓被調用方決定是否需要收集此請求的信息）

這些技術的實現可能是追踪供應商特定的或由應用程序定義的。

tracestate 字段旨在處理針對給定供應商的記錄決策（或其他特定信息）的各種技術。Sampled取樣標誌增強了供應商之間的互操作性。它允許供應商交流記錄決策，並為客戶帶來更好的體驗。

例如，當 SaaS 服務參與分散式追踪時，該服務不知道其呼叫方使用的追踪供應商。此服務可能記錄收入請求的記錄，用於監控或故障排除。Sampled取樣標誌可用於確保呼叫方標記為記錄的請求的信息也將由下游的 SaaS 服務記錄，以便呼叫方可以排除每個記錄請求的行為。

除非在更新 parent-id 時進行變異，否則 Sampled取樣標誌不得受到限制。

以下是供應商SHOULD使用的一套建議，以增加供應商的互操作性：

• 如果組件做出了最終的記錄決策 - 此決策應在 取樣標誌中反映。
• 如果組件需要做出記錄決策 - 它SHOULD尊重 取樣標誌的值。SHOULD應用安全考慮以防止此標誌的濫用或惡意使用。
• 如果組件推遲或延遲了決策並且只有一部分遙測將被記錄，則應不變地傳播 取樣標誌。當由此組件發起追踪時，默認選項應設置為 0。

供應商可以選擇以下兩個額外選項：

• 可以通過為請求的一部分設置 取樣標誌為 1，來傳達記錄的優先級。
• 供應商還可以回退到概率取樣，並為請求的一部分設置 取樣標誌為 1。

3.2.2.5.2 其他標誌

其他標誌的行為（例如 00000100）未定義，並保留供將來使用。供應商必須將這些設置為零。

3.2.3 traceparent header的HTTP示例

呼叫方取樣此請求的有效 traceparent：

Value = 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
base16（版本）= 00
base16（trace-id）= 4bf92f3577b34da6a3ce929d0e0e4736
base16（parent-id）= 00f067aa0ba902b7
base16（trace-flags）= 01 // 取樣

呼叫方未取樣此請求的有效 traceparent：

Value = 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-00
base16（版本）= 00
base16（trace-id）= 4bf92f3577b34da6a3ce929d0e0e4736
base16（parent-id）= 00f067aa0ba902b7
base16（trace-flags）= 00 // 未取樣

3.2.4 traceparent 版本控制

此規範對追踪上下文的未來版本持有意見。此規範的當前版本假定未來的 traceparent header版本將在當前版本的基礎上增加。

在解析具有意外格式的header時，供應商MUST遵循以下規則：

• 貫穿服務不應分析版本。它們應預期未來的header可能具有更大的大小限制，並且只禁止過大的header。
• 如果無法解析版本前綴（不是 2 個十六進制字符，後跟短劃線（-）），實現應重新開始追踪。
• 如果檢測到更高版本，實現SHOULD嘗試通過以下方式解析它：
  • 如果header的大小短於 55 個字符，供應商不應解析header，並應重新開始追踪。
  • 解析 trace-id（從第一個短劃線到下一個 32 個字符）。供應商MUST檢查這 32 個字符是否為十六進制，並且其後是否有短劃線。
  • 解析 parent-id（從第二個短劃線的第 35 個位置到下一個 16 個字符）。供應商必須檢查這 16 個字符是否為十六進制並且其後是否有短劃線。
  • 解析 標誌的 取樣位（從第三個短劃線的 2 個字符）。供應商MUST檢查這 2 個字符是否是字符串的結尾或短劃線。
    如果所有三個值都成功解析，供應商應使用它們。

供應商MUST NOT解析或假設有關此版本的未知字段的任何事物。供應商MUST使用這些字段根据實施所熟知的規範的最高版本（在此規範中是 00）來構建新的 traceparent 字段。

總結

第 3 章至 3.2.4 部分的總結：
在此範圍內，規範主要集中在分散式追踪的 traceparent 頭部和相關機制。

取樣標誌（Sampled Flag）: 規範解釋了取樣標誌的使用，這是一個二進制位，用於指示追踪是否被記錄。當設置時，最低有效位（最右邊）表示呼叫方可能已記錄追踪數據；當未設置時，表示呼叫方未記錄追踪數據。

記錄決策: 這部分還介紹了一些記錄追踪的技術和挑戰，包括概率取樣、延遲決策和推遲取樣。這些技術可以由追踪供應商特定或應用程序定義。

互操作性: 取樣標誌有助於供應商之間的互操作性，允許他們通過不同的技術溝通記錄決策，並為客戶提供更好的體驗。

版本控制: 規範也描述了如何處理 traceparent 的版本控制和未知字段。當解析具有意外格式的header時，供應商必須遵循特定的規則。

安全和最佳實踐: 這部分還包括了一些供應商應遵循的建議和規則，以增加供應商之間的互操作性，並保護此標誌不受濫用或惡意使用。

保留字段: 除了取樣標誌外，還有一些保留字段未定義，供未來使用。

示例: 提供了一些關於如何在不同情況下使用 traceparent header的有效示例。

總的來說，此部分的規範涵蓋了分散式追踪中的取樣機制，解釋了如何使用和解釋取樣標誌，以及如何處理追踪數據的收集和傳播。這為實現分散式系統中的追踪提供了明確的指導和標準。